System and method for providing latency protection for trading orders

ABSTRACT

A system for managing trading orders comprises a memory operable to store an order associated with a first price. The system further comprises a processor communicatively coupled to the memory and operable to identify a latency value. The processor is further operable to receive a counterorder and to identify a potential trade associated with the order and the counterorder, the potential trade based at least in part on the first price. If the latency value satisfies a configurable condition, the processor is further operable to initiate a configurable period of time. If the potential trade is not valid upon expiration of the configurable period, the processor is further operable to prevent the execution of the potential trade.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a continuation of U.S. patent applicationSer. No. 13/169,690, which was filed Jun. 27, 2011 now U.S. Pat. No.8,341,071, which is a continuation of U.S. patent application Ser. No.12/687,938 (now U.S. Pat. No. 7,970,695), which was filed Jan. 15, 2010,which is a continuation application of U.S. patent application Ser. No.11/623,734 (now U.S. Pat. No. 7,716,118), which was filed Jan. 16, 2007,the disclosures of which are hereby incorporated by reference herein intheir entireties.

TECHNICAL FIELD OF THE INVENTION

The present invention relates generally to electronic trading and morespecifically to a system and method for providing latency protection fortrading orders.

BACKGROUND OF THE INVENTION

In recent years, electronic trading systems have gained widespreadacceptance for the trading of a variety of items, such as goods,services, stocks, bonds, currencies, and commodities. In traditionaltrading systems, traders may submit electronic trading orders to thetrading system over networks. The network transmission speed for onetrader may be faster than the network transmission speed for anothertrader. In a fast moving market, the trader associated with the slowernetwork connection may be at a significant disadvantage. In particular,when market conditions change, the trader may want to cancel apreviously submitted order. As a result, the trader may transmit to thetrading system a request to cancel the order. The slow networkconnection, however, may cause the trader's request to arrive at thetrading system after a counterorder from another trader. In suchsituations, traditional trading systems match the counterorder to thepreviously submitted order. The result is a trade that is unwanted bythe trader with the slower network connection. The execution of unwantedtrades may discourage traders from engaging in trading activity.

SUMMARY OF THE INVENTION

In accordance with the present invention, the disadvantages and problemsassociated with prior electronic trading systems have been substantiallyreduced or eliminated.

In some embodiments, a system for managing trading orders comprises amemory operable to store an order associated with a first price. Thesystem further comprises a processor communicatively coupled to thememory and operable to identify a latency value. The processor isfurther operable to receive a counterorder and to identify a potentialtrade associated with the order and the counterorder, the potentialtrade based at least in part on the first price. If the latency valuesatisfies a configurable condition, the processor is further operable toinitiate a configurable period of time. If the potential trade is notvalid upon expiration of the configurable period, the processor isfurther operable to prevent the execution of the potential trade.

The invention has several important technical advantages. Variousembodiments of the invention may have none, some, or all of theseadvantages. One advantage is that the trading system is operable tomonitor and compensate for latency in the system. In particular, uponidentifying a potential trade involving an order and counterorder, thetrading system is operable to record the potential trade in a timerqueue associated with a configurable period of time. Upon expiration ofthe configurable period of time, the trading system is operable todetermine whether the potential trade is still valid. If the tradingsystem determines that the potential trade is no longer valid, thetrading system may prevent the execution of the potential trade. Thus,the trading system may prevent the execution of unwanted trades. Thetrading system may thereby encourage traders to participate in tradingactivity. An increase in trading activity may increase liquidity in thetrading system.

Other advantages will be readily apparent to one having ordinary skillin the art from the following figures, descriptions, and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and itsadvantages, reference is now made to the following description, taken inconjunction with the accompanying drawings, in which:

FIG. 1 illustrates one embodiment of a trading system in accordance withthe present invention;

FIG. 2 illustrates a memory comprising order books, a latency value log,configurable conditions, an inbound queue, and a timer queue, accordingto certain embodiments; and

FIG. 3 illustrates a flowchart for providing latency protection fortrading orders, according to certain embodiments.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 illustrates one embodiment of a trading system 10. Trading system10 may comprise clients 20, manager servers 30, gateway servers 40, anda trading platform 50 communicatively coupled by one or more networks60. Generally, trading system 10 is operable to receive, process, andmatch trading orders 12 from clients 20. Trading system 10 is furtheroperable to monitor latency associated with communications in tradingsystem 10. In particular, trading system 10 may determine latency values14 associated with one or more components in trading system 10. If aparticular latency value 14 satisfies a configurable condition 16,trading system 10 may monitor a potential trade for a configurableperiod 18 of time prior to executing the potential trade. If, uponexpiration of the configurable period 18, trading system 10 determinesthat the potential trade is not valid, trading system 10 may preventexecution of the potential trade. By monitoring potential trades duringconfigurable period 18, trading system 10 may protect traders 22 againstunwanted trades.

Trading system 10 may comprise one or more clients 20. Client 20represents any suitable local or remote end-user device that may be usedby traders 22 to access one or more elements of trading system 10, suchas trading platform 50. A particular client 20 may comprise a computer,workstation, telephone, Internet browser, electronic notebook, PersonalDigital Assistant (PDA), pager, or any other suitable device (wireless,wireline, or otherwise), component, or element capable of receiving,processing, storing, and/or communicating information with othercomponents of trading system 10. Client 20 may also comprise anysuitable user interface such as a display, microphone, keyboard, or anyother appropriate terminal equipment according to particularconfigurations and arrangements. It will be understood that tradingsystem 10 may comprise any number and combination of clients 20. In someembodiments, client 20 may comprise a graphical user interface (GUI) 24.

GUI 24 is generally operable to tailor and filter data presented totrader 22. GUI 24 may provide trader 22 with an efficient anduser-friendly presentation of trading orders 12, market data, and/orother suitable information. GUI 24 may comprise a plurality of displayshaving interactive fields, pull-down lists, and buttons operated bytrader 22. In one example, GUI 24 presents relevant market data totrader 22 and conceals the remaining information to reduce visualclutter. Then, upon receiving a request from trader 22, GUI 24 expandsthe visual representation of market data to display trading history,trading volumes, credit limits, and/or other suitable information. GUI24 may include multiple levels of abstraction including groupings andboundaries. It should be understood that the term graphical userinterface may be used in the singular or in the plural to describe oneor more graphical user interfaces 24 and each of the displays of aparticular graphical user interface 24.

Clients 20 are operable to receive trading orders 12 and change orders26 from traders 22. Clients 20 are further operable to send tradingorders 12 and change orders 26 to gateway server 40. Trading orders 12may comprise orders to trade products such as, for example, currencies,financial instruments, stocks, bonds, futures contracts, equitysecurities, mutual funds, options, derivatives, commodities, or anynumber and combination of suitable trading products. Trading orders 12may comprise bids, offers, market orders, limit orders, stop lossorders, day orders, open orders, GTC (“good till cancelled”) orders,“good through” orders, “all or none” orders, “any part” orders, or anyother suitable order for trading.

A particular trading order 12 may be referred to as an order 12 a or acounterorder 12 b. Orders 12 a and counterorders 12 b representcomplementary actions such as, for example, buying and selling. If theparty that submits a particular order 12 a is referred to as trader 22,then the party that submits a corresponding counterorder 12 b may bereferred to as a “counterparty” trader 22. If a particular order 12 arepresents a buy order (e.g., bid, take, lift, etc.), then acorresponding counterorder 12 b may represent a sell order (e.g., offer,hit, etc.). Conversely, if a particular order 12 a represents a sellorder, then a corresponding counterorder 12 b may represent a buy order.

Change orders 26 may comprise orders to cancel and/or modify apreviously submitted trading order 12. In some embodiments, aftersubmitting trading order 12, trader 22 may later decide that he or sheno longer wants to execute trading order 12. In this situation, trader22 may submit a particular change order 26 that instructs tradingplatform 50 to cancel trading order 12. Upon receiving the particularchange order 26, trading platform 50 may delete, deactivate, and/orignore trading order 12. In other embodiments, after submitting tradingorder 12 for a particular trading product at a particular price, trader22 may later decide that he or she wants to execute the trade at adifferent price and/or with a different quantity. In this situation,trader 22 may submit change order 26 that instructs trading platform 50to change the price, quantity, and/or other suitable characteristic oftrading order 12.

Although clients 20 are described herein as being used by “traders”, itshould be understood that the term “trader” is meant to broadly apply toany user of trading system 10, whether that user is an agent acting onbehalf of a principal, an individual, a legal entity (such as acorporation), or any machine or mechanism that is capable of placingand/or responding to trading orders 12 in trading system 10. Certaintraders 22 in trading system 10 may be associated with market makers 28.

Market maker 28 may refer to any individual, firm, or other entity thatsubmits and/or maintains either or both bid and offer trading orders 12simultaneously for the same instrument. For example, a market maker 28may be a brokerage or bank that maintains either a firm bid and/or offerprice in a given security by standing ready, willing, and able to buyand/or sell that security at publicly quoted prices. A market maker 28generally displays bid and/or offer prices for specific numbers ofspecific securities, and if these prices are met, the market maker 28will immediately buy for and/or sell from its own accounts. According tocertain embodiments, a single trading order 12 may be filled by a numberof market makers 28 at potentially different prices.

In some embodiments, market makers 28 may include individuals, firms orother entities that are granted particular privileges such that tradingorders 12 received from such individuals, firms or other entities aretreated as being received from a traditional market maker 28 (such as abrokerage or bank, for example). For example, certain individuals, firmsor other entities that may otherwise be treated as individual traders 22may be granted privileges to be treated as market makers 28 for thepurposes of the systems and methods discussed herein. To receive marketmaker privileges, an individual, firm or other entity may be required topay a fee, pay a commission, or submit and/or simultaneously maintainboth bid and offer trading orders 12 for particular instruments.According to certain embodiments, an individual, firm or other entitymay be designated as a market maker 28 for particular instruments but asa non-market maker for other instruments.

In some embodiments, a multi-tiered system of market makers 28 may beemployed. Trading platform 50 may grant different privileges todifferent market makers 28 based on one or more criteria such as, forexample, whether the market maker 28 is associated with an electronicfeed, whether the market maker 28 is a strong trader 22, or whether themarket maker 28 has particular information. Market makers 28 may becategorized into different tiers for different tradable instruments. Forinstance, a particular market maker 28 may be categorized as afirst-level market maker 28 for instrument(s) for which that marketmaker 28 is a strong trader 22 and as a second-level market maker 28 forother types of instruments.

In some embodiments, clients 20 may be communicatively coupled tomanager server 30. The combination of a particular manager server 30 andone or more clients 20 may represent a computer system maintained andoperated by a particular market maker 28. Manager server 30 associatedwith a particular market maker 28 is generally operable to monitortrading orders 12 submitted by traders 22 associated with the particularmarket maker 28. Manager server 30 may regulate credit extended to othermarket makers 28 and/or traders 22 in trading system 10.

In some embodiments, manager server 30 is operable to monitor latency intrading system 10. Latency generally refers to delays associated withcommunications between and/or functions performed by various componentsin trading system 10. Latency in trading system 10 may be associatedwith a number of sources. For example, latency may be attributed, atleast in part, to clients 20, manager servers 30, network 60, gatewayservers 40, trading platform 50, and/or any number and combination ofhardware and/or software components in trading system 10.

According to certain embodiments, manager server 30 may determine one ormore latency values 14 associated with various components in tradingsystem 10. Latency value 14 may represent delays associated with thetransmission and/or processing of trading orders 12 in trading system10. In some embodiments, latency value 14 may be based at least in parton the amount of time it takes for trading platform 50 to acknowledgereceipt of trading order 12 transmitted from manager server 30. Due tochanging conditions in network 60 and trading system 10, latency value14 may fluctuate over time. Different market makers 28 and/or clients 22may be associated with different latency values 14. At a given time, aparticular latency value 14 associated with network communicationsbetween a first manager server 30 and trading platform 50 may bedifferent from another latency value 14 associated with networkcommunications between a second manager server 30 and trading platform50.

According to certain embodiments, manager server 30 is operable to usean acceptance message 32 and/or a test order 34 to determine latencyvalue 14. Acceptance message 32 represents a communication from tradingplatform 50 acknowledging receipt of trading order 12, change order 26,and/or test order 34. For example, upon determining that a particulartrading order 12 has been received from a particular manager server 30,trading platform 50 is operable to generate acceptance message 32.Trading platform 50 may then transmit acceptance message 32 to theparticular manager server 30. The particular manager server 30 maycalculate latency value 14 based at least in part on the time at whichtrading order 12 was sent from manager server 30 and/or the time atwhich manager server 30 received acceptance message 32 from tradingplatform 50. In some embodiments, trading order 12 may comprise a timevalue that represents the time at which manager server 30 transmittedtrading order 12 to trading platform 50. Manager server 30 is operableto store time value(s) representing the time at which manager server 30received trading order 12 from client 20, the time at which managerserver 30 transmitted trading order 12 to trading platform 50, the timeat which manager server 30 received acceptance message 32 from tradingplatform, and/or the time(s) associated with any number and combinationof events.

Test order 34 represents an order for an artificial trading product. Insome embodiments, test order 34 is a dummy order or an artificial order.Because test order 34 is associated with an artificial trading product,trading platform 50 does not execute any trades involving test orders34. A particular test order 34 may be associated with a time value thatrepresents the time at which manager server 30 transmitted test order 34to trading platform 50. In some embodiments, in response to receivingtest order 34, trading platform 50 may generate and transmit acceptancemessage 32 to manager server 30. Based at least in part on the time atwhich manager server 30 transmitted test order 34 and on the time atwhich manager server 30 received acceptance message 32, manager server30 may determine latency value 14.

In other embodiments, latency value 14 may be based at least in part onthe amount of time associated with the one-way transmission of testorder 34 and/or other message(s). For example, test order 34 maycomprise a particular time value representing the time at which managerserver 30 transmitted test order 34 to trading platform 50. Uponreceiving test order 34, trading platform 50 may, based at least in parton the particular time value in test order 34 and the time at whichtrading platform 50 received test order 34, determine latency value 14associated with the one-way transmission of test order 34 from managerserver 30.

In some embodiments, manager server 30 may be configured to occasionallytransmit test orders 34 to trading platform 50. For example, managerserver 30 may be configured to transmit test orders 34 at configurableintervals. By periodically sending test orders 34, manager server 30 maycalculate and monitor latency values 14 on an ongoing basis.

In some embodiments, manager server 30 is operable to transmit latencyvalues 14 to trading platform 50. In response to receiving latencyvalues 14 from manager server 30, trading platform 50 may adjustconditions in network 60 or trading system 10. Based at least in part onlatency values 14, trading platform 50 may take measures to compensatefor and/or reduce latency in trading system 10.

Manager server 30 may comprise any suitable combination of hardwareand/or software implemented in one or more modules to provide thedescribed functions and operations. In some embodiments, manager server30 may comprise a general-purpose personal computer (PC), a Macintosh, aworkstation, a Unix-based computer, a server computer, or any suitableprocessing device. Manager server 30 may comprise manager memory 36 andmanager processor 38.

Manager memory 36 comprises any suitable arrangement of random accessmemory (RAM), read only memory (ROM), magnetic computer disk, CD-ROM, orother magnetic or optical storage media, or any other volatile ornon-volatile memory devices that store one or more files, lists, tables,or other arrangements of information such as trading orders 12. AlthoughFIG. 1 illustrates manager memory 36 as internal to manager server 30,it should be understood that manager memory 36 may be internal orexternal to components of trading system 10, depending on particularimplementations. Also, manager memory 36 may be separate from orintegral to other memory devices to achieve any suitable arrangement ofmemory devices for use in trading system 10. According to certainembodiments, manager memory 36 may comprise one or more order logs 42,acceptance messages 32, latency values 14, and manager rules 44.

Order log 42 comprises a log of trading orders 12, change orders 26,and/or test orders 34 transmitted from manager server 30 to tradingplatform 50. In association with each trading order 12, change order 26,and/or test order 34, order log 42 may store the time at which theparticular trading order 12, counterorder 12 b, or trading order 12 wassent to trading platform 50. In addition, or alternatively, to storingorder log 42, manager memory 36 may store one or more acceptancemessages 32 received from trading platform 50. Manager memory 36 mayfurther store latency values 14 calculated by manager server 30.

Manager rules 44 comprise software instructions for routing and/orprocessing trading orders 12 and/or change orders 26 from clients 20.Manager rules 44 further comprise instructions for generating testorders 34, calculating latency values 14, and regulating tradingactivity associated with market maker 28.

Manager memory 36 may be communicatively coupled to manager processor38. Manager processor 38 is generally operable to execute manager rules44 stored in manager memory 36. Manager processor 38 comprises anysuitable combination of hardware and software implemented in one or moremodules to provide the described function or operation.

In some embodiments, trading platform 50 may be associated with aninternal manager server 30. The internal manager server 30 may beoperated by the business entity that maintains and/or operates tradingplatform 50. In some embodiments, the internal manager server 30 may bedirectly coupled to gateway server 40. Thus, communications between theinternal manager server 30 and gateway server 40 may not be routedthrough network 60. The internal manager server 30 may be configured togenerate and transmit test orders 34 to trading platform 50. In responseto receiving test orders 34, trading platform 50 may transmit acceptancemessages 32 to the internal manager server 30. The internal managerserver 30 may calculate latency values 14 and transmit the calculatedlatency values 14 to trading platform 50. Thus, trading system 10 maymonitor the latency associated with the interfaces, components, and/orservers that not associated with network 60 and/or that are internal tothe business entity that maintains and/or operates trading platform 50.

Manager servers 30 may be communicatively coupled to gateway servers 40.Gateway servers 40 generally support communication between clients 20,manager servers 30, and trading platform 50. As clients 20 log intotrading system 10, gateway servers 40 may perform authentication, loadbalancing, and/or other suitable functions. A particular gateway server40 may comprise any suitable combination of hardware and/or softwareimplemented in one or more modules to provide the described functionsand operations. In some embodiments, gateway server 40 may comprise ageneral-purpose personal computer (PC), a Macintosh, a workstation, aUnix-based computer, a server computer, or any suitable processingdevice.

Gateway server 40 may be communicatively coupled to trading platform 50.Trading platform 50 is generally operable to process, route, and matchtrading orders 12 from traders 22. Trading platform 50 is operable toprocess trading orders 12 by filling orders 12 a with one or morecorresponding counterorders 12 b. Trading platform 50 may include anysuitable combination of hardware, software, personnel, devices,components, elements, or objects that may be utilized or implemented toachieve the operations and functions of an administrative body or asupervising entity that manages or administers a trading environment. Insome embodiments, trading platform 50 may comprise platform memory 46and platform processor 48.

Platform memory 46 comprises any suitable arrangement of random accessmemory (RAM), read only memory (ROM), magnetic computer disk, CD-ROM, orother magnetic or optical storage media, or any other volatile ornon-volatile memory devices that store one or more files, lists, tables,or other arrangements of information such as trading orders 12. AlthoughFIG. 1 illustrates platform memory 46 as internal to trading platform50, it should be understood that platform memory 46 may be internal orexternal to components of trading system 10, depending on particularimplementations. Also, platform memory 46 may be separate from orintegral to other memory devices to achieve any suitable arrangement ofmemory devices for use in trading system 10. According to certainembodiments, platform memory 46 may comprise inbound queue 52, orderbooks 54, latency value log 56, configurable conditions 16, timer queue58, and platform rules 62.

Inbound queue 52 may represent an intake queue of trading orders 12,change orders 26, and/or test orders 34 received from gateway server 40.Prior to performing the initial processing of a particular trading order12, change order 26, and/or test order 34, trading platform 50 may storethe particular trading order 12, change order 26, and/or test order 34in inbound queue 52. The trading orders 12, change orders 26, and/ortest orders 34 in inbound queue 52 may be stored in chronologicalsequence and processed according to a first-in first-out (“FIFO”)sequence. Once a particular trading order 12, change order 26, and/ortest order 34 has passed through inbound queue 52, trading platform 50may generate acceptance message 32 and assign trading order 12, changeorder 26, and/or test order 34 to the appropriate order book 54 inplatform memory 46. In some embodiments, because trading platform 50 maygenerate acceptance message 32 after trading order 12, change order 26,and/or test order 34 passes through inbound queue 52, latency value 14may be based at least in part on inbound queue 52.

Order books 54 represent queues, tables, or lists for storing, sorting,and processing information regarding trading orders 12 received fromtraders 22. Each order book 54 in memory may be associated with arespective trading product. In some embodiments, a particular order book54 may be associated with a particular type of trading order 12. Forexample, platform memory 46 may comprise a first order book 54associated with a first security and a second order book 54 associatedwith a second security. In some embodiments, a particular tradingproduct may be associated with a first order book 54 for bids (e.g.,“bid book”) and a second order book 54 for offers (e.g., “offer book”).

Trading platform 50 may monitor trading orders 12 in order books 54 toidentify matches between orders 12 a and counterorders 12 b. In someembodiments, order 12 a and counterorder 12 b match if they are for thesame trading product and for the same price. For example, a bid forTrading Product X at $10.00 per unit matches an offer of Trading ProductX at $10.00 per unit. According to certain embodiments, trading platform50 may match order 12 a and counterorder 12 b if their prices cross. Forexample, trading platform 50 may match a bid for Trading Product X at$10.00 per unit with an offer of Trading Product X at $9.00 per unit. Incertain embodiments, counterorder 12 b may be an aggressive tradingorder 12 that does not specify a particular trading product. Forexample, counterorder 12 b may be a “hit” for Trading Product X thattargets the current best bid price. Accordingly, if the best bid forTrading Product X is associated with a price of $11, trading platform 50may match the “hit” to the bid and execute the trade at a price of $11.It should be understood that trading platform 50 is operable to matchorders 12 a and counterorders 12 b of any suitable type and for anysuitable trading product.

Upon identifying a match between order 12 a and counterorder 12 b inorder book 54, trading platform 50 may generate a potential trade record64. Potential trade record 64 represents an entry, message, or othersuitable indicator that a match has been identified between a particularorder 12 a and a particular counterorder 12 b. Potential trade record 64may indicate the particular order 12 a and counterorder 12 b that havebeen identified as matching. Trading platform 50 may then store thepotential trade record 64 in timer queue 58.

Timer queue 58 represents a queue, table, or list for storing andmanaging potential trade records 64. Timer queue 58 may be associatedwith a configurable period 18 of time. When a particular trade record isstored in timer queue 58, trading platform 50 may initiate theconfigurable period 18. When the configurable period 18 expires, tradingplatform 50 may determine whether the particular order 12 a andcounterorder 12 b associated with the potential trade record 64 stillmatch. If the particular order 12 a and counterorder 12 b match uponexpiration of the configurable period 18, trading platform 50 mayexecute a trade with the particular order 12 a and counterorder 12 b.However, if the particular order 12 a and counterorder 12 b do not matchupon expiration of the configurable period 18, trading platform 50 mayprevent the trade involving the particular order 12 a and counterorder12 b.

In some embodiments, timer queue 58 may be associated with a callbackfunction. When the configurable period 18 expires, platform processor 48may be notified and prompted to determine whether the particular order12 a and counterorder 12 b associated with the potential trade record 64still match. In some embodiments, timer queue 58 may store multiplepotential trade records 64. As each potential trade record 64 is enteredin timer queue 58, a respective configurable period 18 may be initiatedfor that potential trade record 64. Thus, configurable period 18 for afirst potential trade record 64 may, in some embodiments, overlap withconfigurable period 18 for a second potential trade record 64.

During configurable period 18 associated with a particular order 12 aand counterorder 12 b, the particular order 12 a and counterorder 12 bmay remain listed in order books 54. According to certain embodiments,trading platform 50 may receive, during configurable period 18, changeorder 26 associated with the particular order 12 a or counterorder 12 b.In some embodiments, trading platform 50 may cancel the particular order12 a or counterorder 12 b based at least in part on received changeorder 26. In other embodiments, trading platform 50 may change theprice, the quantity, and/or other characteristic of order 12 a orcounterorder 12 b based at least in part on the received change order26. If change order 26 causes the particular order 12 a and counterorder12 b to not match, then, upon expiration of configurable period 18,trading platform 50 may prevent the execution of a trade between theparticular order 12 a and counterorder 12 b.

In some embodiments, preventing the execution of the trade between order12 a and counterorder 12 b may comprise deleting order 12 a and/orcounterorder 12 b from order book 54, moving order 12 a or counterorder12 b to a different order book 54, assigning market priority to a thirdtrading order 12, and/or matching order 12 a or counterorder 12 b with athird trading order 12.

An example illustrates certain embodiments. Trader A submits to tradingplatform 50 Bid A for Trading Product X at $10.00 per share. Tradingplatform 50 stores Bid A in order book 54. Subsequently, Trader Bsubmits to trading platform 50 Offer B for Trading Product X at $10.00per share. Trading platform 50 stores Offer B in order book 54 andidentifies a match between Bid A and Offer B. Trading platform 50generates potential trade record 64 associated with Bid A and Offer Band stores potential trade record 64 in timer queue 58. Upon storingpotential trade record 64 in timer queue 58, trading platform 50initiates configurable period 18. During configurable period 18, tradingplatform 50 receives change order 26 from Trader A. Change order 26directs trading platform 50 to cancel Bid A. Accordingly, tradingplatform 50 cancels Bid A. In this example, trading platform 50 deletesBid A from order book 54. Subsequently, configurable period 18 expires.Upon expiration of configurable period 18, platform processor 48 scansfor Bid A and Offer B in order book(s) 54 and determines that, becauseBid A was canceled, there is no match between Bid A and Offer B.Accordingly, trading platform 50 does not execute trade involving Bid Aand Offer B.

In the foregoing example, if trading platform 50 had, upon initiallyidentifying the match, executed a trade involving Bid A and Offer Brather than initiate the configurable period 18, the particular changeorder 26 from Trader A would not have been received in time to preventthe trade. If Trader A submitted the particular change order 26 prior toOffer B and if the particular change order 26 was delayed due to latencyin trading system 10, the latency in trading system 10 would havecontributed to the execution of a trade that Trader A did not want. Theexecution of unwanted trades may discourage Trader A from submittingtrading orders 12. Thus, by avoiding the execution of unwanted trades,trading platform 50 may increase the number of trading orders 12submitted by traders 22, which may increase liquidity in trading system10.

In the foregoing example, the price of Trading Product X was expressedin dollars. It should be understood, however, that the price of aparticular trading product may be expressed according to any currency,rate, or other suitable unit.

As explained above, platform memory 46 may comprise latency value log56. Latency value log 56 comprises one or more latency values 14received from manager servers 30 and/or determined by trading platform50. In some embodiments, latency value log 56 may comprise latencyvalues 14 associated with clients 20, manager servers 30, gateway server40, trading platform 50, network 60, and/or any number and combinationof hardware and/or software in trading system 10. According to certainembodiments, latency value log 56 may comprise historic latency values14 associated with a particular manager server 30. In other embodiments,latency value log 56 may comprise a plurality of current latency values14, wherein each current latency value 14 is associated with arespective manager server 30.

Platform memory 46 may further comprise one or more configurableconditions 16. Configurable condition 16 may specify a threshold,limitation, characteristic, and/or criteria associated with latencyvalues 14 in latency value log 56 and/or with configurable period 18associated with timer queue 58. For example, configurable condition 16may specify that, if latency value 14 in latency value log 56 satisfiesa configurable threshold, then configurable period 18 is set to aparticular amount of time. As another example, configurable condition 16may specify that, if latency value 14 does not satisfy a configurablethreshold, then configurable period 18 is set to zero. Thus,configurable period 18 may be based at least in part on latency value(s)14 in latency value log 56. It should be understood that platform memory46 may comprise any suitable number and combination of configurableconditions 16.

In some embodiments, upon receiving trading order 12, trading platform50 may determine the particular trader 22, client 20, and/or managerserver 30 that submitted trading order 12. According to certainembodiments, configurable period 18 associated with a particular tradingorder 12 may based at least in part on the particular trader 22, client20, and/or manager server 30 that submitted the particular trading order12. For example, trading order 12 from client 20 and/or manager server30 associated with a particular latency value 14 may be assigned adifferent configurable period 18 than trading order 12 from a differentclient 20 and/or manager server 30 associated with a different latencyvalue 14.

As explained above, platform memory 46 may comprise platform rules 62.Platform rules 62 comprise software instructions for performing thedescribed functions and operations.

Platform memory 46 may be communicatively coupled to platform processor48. Platform processor 48 is generally operable to execute platformrules 62 stored in platform memory 46. Platform processor 48 comprisesany suitable combination of hardware and software implemented in one ormore modules to provide the described function or operation.

It should be understood that the internal structure of trading platform50 and the interfaces, processors, and memory devices associatedtherewith is malleable and can be readily changed, modified, rearranged,or reconfigured to achieve the intended operations of trading platform50.

As explained above, clients 20, manager servers 30, gateway servers 40,and trading platform 50 may be communicatively coupled via one or morenetworks 60. Network 60 may represent any number and combination ofwireline and/or wireless networks suitable for data transmission.Network 60 may, for example, communicate internet protocol packets,frame relay frames, asynchronous transfer mode cells, and/or othersuitable information between network addresses. Network 60 may includeone or more intranets, local area networks, metropolitan area networks,wide area networks, cellular networks, all or a portion of the Internet,and/or any other communication system or systems at one or morelocations.

It should be understood that the internal structure of trading system 10and the servers, processors, and memory devices associated therewith ismalleable and can be readily changed, modified, rearranged, orreconfigured to achieve the intended operations of trading system 10. Inparticular, although FIG. 1 illustrates gateway server 40 as separatefrom trading platform 50, it should be understood that, in someembodiments, trading platform 50 may be operable to perform thefunctions and operations of gateway server 40.

In operation, trading system 10 is operable to use and manage latencyvalues 14 in processing trading orders 12. According to certainembodiments, manager server 30 may generate and transmit test order 34to trading platform 50. Trading platform 50 may store test order 34 ininbound queue 52 in memory. Upon retrieving test order 34 from inboundqueue 52, trading platform 50 may generate and transmit acceptancemessage 32 to manager server 30. In some embodiments, based at least inpart on the time at which manager server 30 transmitted test order 34and on the time at which manager server 30 received acceptance message32, manager server 30 may determine latency value 14. Manager server 30may then transmit latency value 14 to trading platform 50.

In other embodiments, latency value 14 may be associated with theone-way transmission of test order 34 and/or other message(s). Forexample, test order 34 may comprise a particular time value representingthe time at which manager server 30 transmitted test order 34 to tradingplatform 50. Upon receiving test order 34, trading platform 50 may,based at least in part on the particular time value in test order 34 andthe time at which trading platform 50 received test order 34, determinelatency value 14 associated with the one-way transmission of test order34 from manager server 30.

According to certain embodiments, trading platform 50 may receivetrading orders 12 from clients 20. Trading platform 50 may store tradingorders 12 in order books 54 in platform memory 46. Upon identifying amatch between a particular order 12 a and counterorder 12 b in orderbook 54, trading platform 50 may generate in time queue potential traderecord 64 associated with the particular order 12 a and counterorder 12b. Upon generating potential trade record 64, trading platform 50 mayinitiate configurable period 18. Configurable period 18 may be based atleast in part on one or more latecy values 14 received and/or determinedby trading platform 50. During configurable period 18 associated with aparticular order 12 a and counterorder 12 b, the particular order 12 aand counterorder 12 b may remain stored in order books 54.

During configurable period 18, trading platform 50 may receive changeorder 26 associated with the particular order 12 a or counterorder 12 b.In some embodiments, trading platform 50 may cancel the particular order12 a or counterorder 12 b based at least in part on the received changeorder 26. In other embodiments, trading platform 50 may change theprice, the quantity, and/or other characteristic of order 12 a orcounterorder 12 b based at least in part on received change order 26. Ifchange order 26 causes the particular order 12 a and counterorder 12 bto not match, then trading platform 50 may, upon expiration ofconfigurable period 18, prevent the execution of a trade between theparticular order 12 a and counterorder 12 b. Preventing the execution ofthe trade between the particular order 12 a and counterorder 12 b maycomprise deleting the particular order 12 a or counterorder 12 b fromorder book 54, moving the order 12 a or counterorder 12 b to a differentorder book 54, assigning market priority to a third trading order 12,and/or matching the particular order 12 a or counterorder 12 b with athird trading order 12.

FIG. 2 illustrates an example platform memory 46, which comprises orderbooks 54, latency value log 56, configurable conditions 16, inboundqueue 52, and timer queue 58, according to certain embodiments. In thisexample, latency value log 56 comprises latency values 14 associatedwith a plurality of manager servers 30. Each latency value 14 wasreceived from a respective manager server 30. Manager server 30 isoperable to determine latency value 14 based at least in part on testorder 34 and acceptance message 32. In particular, manager server 30transmits test order 34 to trading platform 50. Upon receiving testorder 34, trading platform 50 may generate and transmit acceptancemessage 32 to manager server 30. Based at least in part on the time atwhich manager server 30 transmitted test order 34 and on the time atwhich manager server 30 received acceptance message 32, manager server30 may determine latency value 14. Manager server 30 may then transmitlatency value 14 to trading platform 50.

In this example, latency value log 56 in platform memory 46 compriseslatency values 14 from a plurality of manager servers 30. In particular,Manager Server A is associated with latency value 14 of 0.22 seconds,Manager Server B is associated with latency value 14 of 0.31 seconds,Manager Server C is associated with latency value 14 of 0.57 seconds,and Manager Server D is associated with latency value 14 of 0.12seconds.

The example platform memory 46 further comprises multiple configurableconditions 16. The first configurable condition 16 is that, if alllatency values 14 in latency value log 56 are equal to or less than 0.30seconds, then configurable period 18 is zero. The second configurablecondition 16 is that, if any latency value 14 in latency value log 56 isbetween 0.30 seconds and 0.60 seconds, then configurable period 18 is0.20 seconds. The third configurable condition 16 is that, if anylatency value 14 in latency value log 56 is equal to or more than 0.60seconds, then configurable period 18 is 0.40 seconds.

Although this example illustrates particular latency ranges andparticular configurable periods 18 of time, it should be understood thatlatency ranges and/or other values associated with configurablecondition 16 and/or configurable period 18 may be below, within, orabove the illustrated values and/or ranges.

In this example, platform memory 46 further comprises two order books54—bid book 54 and offer book 54. Initially, bid book 54 comprises Bid Aassociated with a price of $6.00 and Bid B associated with a price of$8.00. Initially, offer book 54 comprises Offer M associated with aprice of $8.00.

Platform processor 48 monitors bid book 54 and offer book 54 to identifyany matches between orders 12 a and counterorders 12 b. In this example,at 14:22:27.04, platform processor 48 determines that Offer M matchesBid B. Platform processor 48 then generates and stores in timer queue 58potential trade record 64 associated with Offer M and Bid B. Becauselatency value log 56 comprises latency values 14 between 0.30 secondsand 0.60 seconds, configurable period 18 associated with timer queue 58is 0.20 seconds. In this example, during configurable period 18,platform processor 48 does not retrieve from timer queue 58 any changeorders 26 associated with Offer M and Bid B. When configurable period 18expires at 14:22:27.24, trading platform 50 scans order books 54 anddetermines that Offer M and Bid B still match. Accordingly, tradingplatform 50 executes a trade with Offer M and Bid B.

Platform processor 48 subsequently retrieves from inbound queue 52 Bid Cassociated with a price of $8.00. Platform processor 48 stores Bid C inbid book 54. Platform processor 48 then retrieves from inbound queue 52Offer N associated with a price of $8.00. After storing Offer N in offerbook 54, platform processor 48 determines, at 14:23:38.24, that Offer Nmatches Bid C. Platform processor 48 then generates and stores in timerqueue 58 potential trade record 64 associated with Offer N and Bid C.During configurable period 18 associated with potential trade record 64for Offer N and Bid C (e.g., prior to 14:23:38.44), platform processor48 retrieves from inbound queue 52 change order 26 that instructsplatform processor 48 to cancel Bid C. As a result, platform processor48 deletes Bid C from bid book 54. In this example, when configurableperiod 18 expires at 14:23:38.44, platform processor 48 scans orderbooks 54 and determines that the previously identified match between BidC and Offer N is no longer valid because Bid C has been canceled.Accordingly, trading platform 50 does not execute a trade with Bid C andOffer N.

The example inbound queue 52 comprises multiple trading orders 12,change orders 26, and test orders 34 waiting to be processed by platformprocessor 48. In this example, test orders 34 in inbound queue 52 arenot associated with prices. Test order 34 represents a dummy orderand/or an artificial order. Because test order 34 is associated with anartificial trading product, trading platform 50 does not execute anytrades involving test orders 34.

In the foregoing example, the price of trading orders 12 was expressedin dollars. It should be understood, however, that the price of aparticular trading product may be expressed according to any currency,rate, or other suitable unit.

In the foregoing example, latency values 14 are expressed in seconds. Itshould be understood, however, that latency values 14 may be expressedaccording to any suitable unit and/or combination of units.

In the foregoing example, manager server 30 determines latency values14. It should be understood that, in some embodiments, manager server 30and/or trading platform 50 may determine latency values 14 that areassociated with one-way and/or round-trip communications.

The foregoing example illustrates configurable periods 18 of 0.20seconds and 0.40 seconds. It should be understood that configurableperiod 18 may be any suitable amount of time.

The invention has several important technical advantages. Variousembodiments of the invention may have none, some, or all of theseadvantages. One advantage is that trading platform 50 is operable tomonitor and compensate for latency in trading system 10. In particular,upon identifying a potential trade involving order 12 a and counterorder12 b, trading platform 50 is operable to enter potential trade record 64in timer queue 58 associated with configurable period 18. Uponexpiration of configurable period 18, trading platform 50 is operable todetermine whether the potential trade is still valid. If tradingplatform 50 determines that the potential trade is no longer valid,trading platform 50 may prevent the execution of the potential trade.Thus, trading system 10 may prevent the execution of unwanted trades.Trading system 10 may thereby encourage traders 22 to participate intrading activity. An increase in trading activity may increase liquidityin trading system 10.

FIG. 3 illustrates a flowchart for providing latency protection fortrading orders 12, according to certain embodiments. The method beginsat step 302 when trading platform 50 receives test order 34 from managerserver 30. Trading platform 50 may initially store test order 34 ininbound queue 52. Upon retrieving test order 34 from inbound queue 52,platform processor 48 may generate acceptance message 32. At step 304,platform processor 48 transmits acceptance message 32 to manager server30. Upon receiving acceptance message 32, manager server 30 determineslatency value 14. Latency value 14 may be based at least in part on theparticular time at which test order 34 was sent to trading platform 50and the particular time at which manager server 30 received acceptancemessage 32. At step 306, platform processor 48 receives latency value 14from manager server 30.

At step 308, platform processor 48 identifies a potential tradeassociated with order 12 a and counterorder 12 b stored in order books54 in platform memory 46. At step 310, platform processor 48 determineswhether the received latency value 14 satisfies configurable condition16. In some embodiments, configurable condition 16 may be associatedwith a latency value threshold. If platform processor 48 determines atstep 310 that latency value 14 does not satisfy configurable condition16, then the method may proceed to step 316. At step 316, platformprocessor 48 executes the trade with order 12 a and counterorder 12 b.

If, however, platform processor 48 determines at step 310 that latencyvalue 14 satisfies configurable condition 16, then at step 312 platformprocessor 48 initiates configurable period 18. Upon expiration of theconfigurable period 18, platform processor 48 determines at step 314whether order 12 a still matches counterorder 12 b. If platformprocessor 48 determines at step 314 that order 12 a still matchescounterorder 12 b, then at step 316 platform processor 48 executes thetrade with order 12 a and counterorder 12 b. If, however, platformprocessor 48 determines at step 314 that order 12 a does not matchcounterorder 12 b, then at step 318 platform processor 48 prevents theexecution of the potential trade. In some embodiments, preventing theexecution of the trade between order 12 a and counterorder 12 b maycomprise deleting order 12 a and/or counterorder 12 b from order book54, moving order 12 a or counterorder 12 b to a different order book 54,assigning market priority to a third trading order 12, and/or matchingorder 12 a or counterorder 12 b with a third trading order 12. Themethod then ends.

Although the present invention has been described in severalembodiments, a myriad of changes and modifications may be suggested toone skilled in the art, and it is intended that the present inventionencompass such changes and modifications as fall within the scope of thepresent appended claims.

What is claimed is:
 1. A system for managing trading orders, comprising:at least one processor; at least one memory communicatively coupled tothe at least one processor and storing instructions that, when executedby the at least one processor, cause the at least one processor to:identify a latency value; receive an order associated with a firstprice; receive a counterorder; identify a potential trade associatedwith the order and the counterorder, the potential trade based at leastin part on the first price; generate a potential trade record based onthe identified potential trade associated with the order and thecounterorder; determine that the latency value satisfies a configurablecondition; responsive to determining that the latency value satisfiesthe configurable condition, initiate a configurable period of time;determine that the potential trade is valid upon expiration of theconfigurable period; and responsive to determining that the potentialtrade is valid upon expiration of the configurable period, cause thepotential trade to be executed.
 2. The system of claim 1, in which theat least one processor comprises a server operable to determine thelatency value.
 3. The system of claim 2, wherein determining the latencyvalue comprises: submitting a test order to a trading platform at afirst time; receiving, at a second time, an acceptance messageassociated with the test order; and calculating the latency value basedat least in part on the first time and the second time.
 4. The system ofclaim 3, wherein the test order is associated with an artificial tradingproduct such that the trading platform allows execution of the testorder.
 5. The system of claim 1, wherein: the counterorder is associatedwith a second price that matches the first price; and the identificationof the potential trade is based at least in part on the second pricematching the first price.
 6. The system of claim 1, wherein, uponexpiration of the configurable period, the at least one processor isfurther operable to determine whether the potential trade is valid. 7.The system of claim 6, wherein: the at least one processor is furtheroperable to receive, prior to expiration of the configurable period, acommand to cancel the order; and the potential trade is determined to beinvalid based at least in part on the received cancel command.
 8. Thesystem of claim 6, wherein: the at least one processor is furtheroperable to receive, prior to expiration of the configurable period, acommand to adjust the first price associated with the order; and thepotential trade is determined to be invalid based at least in part onthe received adjust command.
 9. The system of claim 1, wherein theconfigurable period is based at least in part on the latency value. 10.The system of claim 1, wherein preventing the execution of the potentialtrade comprises deleting the order.
 11. The system of claim 1, wherein,if the potential trade is valid upon expiration of the configurableperiod, the at least one processor is further operable to execute thepotential trade.
 12. The system of claim 11, wherein the potential tradeis valid if the order matches the counterorder upon expiration of theconfigurable period.
 13. The system of claim 1, wherein the configurablecondition is satisfied if the latency value satisfies a thresholddetermined before the order is received.
 14. The system of claim 1,wherein the configurable condition is based at least in part on pricevolatility associated with a trading platform.
 15. The system of claim1, wherein: initiating a configurable period of time comprises storingin a timer queue an entry associated with the identified potentialtrade; and the timer queue is associated with a callback function todetermine whether the order matches the counterorder upon expiration ofthe configurable period.
 16. A method for managing trading orders,comprising: determining, by at least one processor, a latency value;receiving, by the at least one processor, an order associated with afirst price; receiving, by the at least one processor, a counterorder;identifying, by the at least one processor, a potential trade associatedwith the order and the counterorder, the potential trade based at leastin part on the first price; determining, by the at least one processor,that the determined latency value satisfies a configurable condition;responsive to determining that the latency value satisfies theconfigurable condition, initiating, by the at least one processor, aconfigurable period of time; determining, by the at least one processor,that the potential trade is net valid upon expiration of theconfigurable period; and responsive to determining that the potentialtrade is valid upon expiration of the configurable period, causing, bythe at least one processor, the the potential trade to be executed. 17.The method of claim 16, wherein determining the latency value comprises:submitting a test order to a trading platform at a first time;receiving, at a second time, an acceptance message associated with thetest order; and calculating the latency value based at least in part onthe first time and the second time.
 18. The method of claim 17, whereinthe test order is associated with an artificial trading product suchthat the trading platform causes execution of the test order.
 19. Themethod of claim 16, wherein: the counterorder is associated with asecond price that matches the first price; and the identification of thepotential trade is based at least in part on the second price matchingthe first price.
 20. A non-transitory machine-readable medium havinginstructions stored thereon which, when executed, direct at least oneprocessor to: identify a latency value; receive an order associated witha first price; receive a counterorder; identify a potential tradeassociated with the order and the counterorder, the potential tradebased at least in part on the first price; generate a potential traderecord based on the identified potential trade associated with the orderand the counterorder; determine that the latency value satisfies aconfigurable condition; responsive to determining that the latency valuesatisfies the configurable condition, initiate a configurable period oftime; determine that the potential trade is valid upon expiration of theconfigurable period; and responsive to determining that the potentialtrade is valid upon expiration of the configurable period, cause thepotential trade to be executed.